<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Roadmap: How to Adopt the Test Driven Development Practice</title>
<meta name="uma.type" content="Roadmap">
<meta name="uma.name" content="adopt_tdd_practice">
<meta name="uma.presentationName" content="How to Adopt the Test Driven Development Practice">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_8yG48JRqEdyrdaw_xGakyw"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Roadmap: How to Adopt the Test Driven Development Practice</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/roadmap.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This roadmap describes how to adopt the test driven development (TDD) Practice.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><h3>
    Getting Started
</h3>
<p>
    If you have just installed the test driven development (TDD) practice, start by reviewing the <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html" guid="_ADwlAJRtEdyrdaw_xGakyw">Concept: Developer Testing</a>. These will introduce you to the basics of what you need
    to know about developer testing in the context of TDD. For more introductory information, read this <a href="http://www.agiledata.org/essays/tdd.html" target="_blank">Introduction to TDD</a>.
</p>
<p>
    If your organization has never done developer testing before, start your adoption by educating the members of the team.
    Use the resources below for educational and reference materials. Begin to track your performance immediately, because
    that will give you quick feedback on how rapidly the team is adopting TDD, even if it is a very low form of adoption at
    first.
</p>
<p>
    Tools are critical for creating and managing unit tests. Educate the team on using new tools, and discover which
    practices and features of the tools will work best in your environment.
</p>
<p>
    Specify modest, attainable goals when adopting TDD. For instance, instead of insisting that every code change must have
    a developer test starting now, it may be better to limit TDD practices to a single important implementation element.
    This will allow the team to come up to speed on tools and learn new development habits while minimizing the impact on
    the overall schedule. After the team has gained some comfort with the new way of doing things (usually a couple of
    weeks or a single iteration), your refined method for TDD can be applied to all new or changed code. Continue
    increasing the team's capabilities with TDD by introducing new tools, constraints, monitoring, or methods in modest,
    attainable increments. This also allows the team to experience success with new techniques, which usually leads to a
    team that embraces rather than resists change.
</p>
<p>
    Like all process changes, adopting TDD requires that team members change behaviors and develop new habits, such as
    writing code only when a test already exists to validate it. Developers will need the education provided by the links
    on this page, and the methods described in this practice, to develop these new behaviors. They will also need to have
    their new behaviors enforced by the team as a whole, and by management, until constantly writing tests while writing
    code is a habit. TDD is no different from other areas of process adoption. The managing body (bosses or the team) need
    to put as much effort into creating new behaviors as the individual developers do.
</p>
<p>
    <strong>TDD Adoption scenario</strong>
</p>
<p>
    Here is one possible scenario for adopting the TDD practice. You will want to add, change, or remove steps to design an
    adoption roadmap more suitable to your environment. Hiring a consultant experienced in TDD will also speed your
    adoption of the practice and help avoid common pitfalls.
</p>
<ol>
    <li>
        Educate the team on TDD. Use the presentations and articles referenced in this practice as a starting place. It
        would also be helpful for developers to attend a class on developer testing and TDD.
    </li>
    <li>
        Have the team review the material in this practice.
    </li>
    <li>
        Extend this practice to reflect any important constraints or requirements in your organization. For instance,
        indicate any extra information that may need to be described when checking in system or test code, link to any
        materials that describe internal tools that your team is required to use, or create a guideline describing how each
        test must be documented or structured to conform to corporate standards.
    </li>
    <li>
        Identify and prepare to collect the information or metrics that will tell you how well you are adopting this
        practice. Make sure that the metrics are easy to collect. Highly accurate metrics that are difficult to collect are
        often abandoned, so provide no value. Coarser measurements that are easy to collect usually provide sufficient
        information, and it is more likely that they will continue to be collected.
    </li>
    <li>
        Identify the initial, modest goals for your TDD adoption, such as "An average of 2 tests per method for
        implementation element X". The goal is to be successful at some incremental amount of adoption, not to adopt
        everything in a single event. Make success a regular habit.
    </li>
    <li>
        Select a critical system implementation element to start applying TDD on. Begin using new TDD tools and techniques
        to develop and test the code.
    </li>
    <li>
        Select a time frame to evaluate the adoption of new TDD techniques. It should be long enough to allow new habits to
        start to develop, but short enough that changes can be made relatively quickly. This will generally be sometime
        between a couple of weeks and a couple of months.
    </li>
    <li>
        Begin to use TDD as described in the practice. Write tests before writing system code.
    </li>
    <li>
        Evaluate your TDD adoption based on the objectives and metrics that you defined.
    </li>
    <li>
        Make adjustments based on your evaluation. Eliminate tools or tool features that do not prove effective, and
        increase practices that are efficient and improve quality.
    </li>
    <li>
        Determine the next step in adoption. Early on, this will be to write tests for more and more implementation
        elements until TDD is performed on all software for the system. Often, you will be able to achieve this after just
        a few evaluation cycles.
    </li>
    <li>
        Continue to examine how your developer testing can be improved. Address problem areas in regular project review
        meetings. Monitor testing sites (such as the ones referenced on this page), and have individual team members read
        new articles and books about developer testing. They can report back to the group to generate insight and
        discussion about more improvements that can be incrementally applied to your TDD practice.
    </li>
    <li>
        Continue to extend or modify this practice to reflect how your team is performing TDD, and what the next increment
        of adoption should be for your team.
    </li>
</ol>
<h4>
    <br />
    Common pitfalls
</h4>
<p>
    TDD is a new way of thinking about testing. Failing to plan and manage how the team's behavior needs to change over
    time increases the chance of failing at TDD. Keep the team focused on TDD, and watch for the team falling back into old
    habits.
</p>
<p>
    Individuals may opt for expedience and skip "small" or "insignificant" tests in an effort to meet deadlines. TDD's
    payoff is later in the development cycle, when the team is working with a high-quality baseline rather than fixing a
    mountain of bugs that have piled up. No change is too small to be tested.
</p>
<p>
    Individuals may ignore implementation refactoring once the code runs successfully. Implementation refactoring keeps the
    code maintainable and reduces code decay, a phenomenon where the average number of errors created by a code fix
    increases over time. The team must refactor after the code runs successfully in order to maintain stable code that can
    be maintained and improved over the long term.
</p></td>
</tr>
</table>
</div>
<div class="sectionHeading">More Information</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Concepts</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html" guid="_ADwlAJRtEdyrdaw_xGakyw">Developer Testing</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Supporting Materials</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html" guid="_vLvAUGjFEd2PJ-nlV-86WA">Using TDD in context</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
